Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rename the primary grid parameter #65

Merged
merged 13 commits into from
Oct 30, 2024
Merged

rename the primary grid parameter #65

merged 13 commits into from
Oct 30, 2024

Conversation

keewis
Copy link
Collaborator

@keewis keewis commented Sep 26, 2024

With the new name I don't really have an idea on how to describe the parameter in docstrings (level is not as easy to understand as resolution). We could describe it as

the resolution / cell size of the grid

since grids don't have any information content, but not sure if that makes sense. Does anyone have any idea?

@strobpr
Copy link

strobpr commented Sep 26, 2024

a good phrasing for general description and understanding would be 'grid spacing (levels)'. A bit more special is 'cell size (levels)' as only applicable to cell grids (thus ok for DGGS) but not node grids (often coverages).

@benbovy
Copy link
Member

benbovy commented Sep 27, 2024

I would simply say something like this:

level : int
    Grid hierarchical level. A higher value corresponds to a finer grid resolution
    with smaller cell areas. The number of cells covering the whole sphere usually
    grows exponentially (*) with increasing level values, ranging from 5-100 cells
    (level 0) to millions or billions of cells (level 10+).

(*) or as a power function?

@keewis
Copy link
Collaborator Author

keewis commented Sep 27, 2024

I'd probably try to fit "depending on the specific grid" somewhere in the second sentence, but that's already really great (and as far as I can tell, exponential seems right because we're talking about $n^{\mathrm{level}}$, i.e. the base is constant but the power varies)

@benbovy
Copy link
Member

benbovy commented Sep 27, 2024

I'd have been nice to return from a DGGSInfo instance a cell statistics table like those ones: H3, S2. But I don't think that the core libraries provide such thing via their API, unfortunately.

@keewis
Copy link
Collaborator Author

keewis commented Sep 27, 2024

That could indeed be helpful.

For healpy there's hp.nside2npix, which in any case is 12 * 4**level. As far as statistics like min/max/average area and min/max edge length go, this might be trickier but should not be impossible.

I'd say let's open a separate issue to discuss adding a method like that to DGGSInfo.

@strobpr
Copy link

strobpr commented Sep 27, 2024

Did you consider asking the DGGS API experts?

@keewis
Copy link
Collaborator Author

keewis commented Oct 28, 2024

assuming this is fine (we did have extensive discussion elsewhere), I'm going to merge this tomorrow.

@keewis
Copy link
Collaborator Author

keewis commented Oct 30, 2024

merging. We can always improve later, should it become necessary.

@keewis keewis merged commit d88c077 into xarray-contrib:main Oct 30, 2024
11 checks passed
@keewis keewis deleted the level branch October 30, 2024 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

renaming the primary grid parameter from resolution to level
3 participants